The '\tVinWi~ Spiral Soft,vare Process Model

ion where each level .'is a decomposition of the higher one. In WinWin, the process --actions are situated and do not have hierarchical levels of decomposition. The problem of scalability arises from the complexity of managing the artifacts. win conditions, conflicts, and points of agreement that result from stakeholder actions as opposed to planning and execution of complex process instances. This resulted in WinWin-O not being able to scale up with the complexity of win conditions, contHcts, and points of agreement for complex and large systems. In Win Win-I, the scalability issue is handled by i) explicitly distinguishing a minimum set of objects that correspond to the Win \Vin conceptual entities of win conditions CN), Conflict/R.isk/ Uncertainty (henceforth referred to as the issue, I, in short), options (0) and Points of Agreements (henceforth referred to as the Agreement. A, in short), and ii) providing a level of structuring that attempts to strike a balance between the tasks of the stakeholder and the support tool. The attributes defined for each artifact facilitate the tractable management of the artifacts that result from the process actions Table 2 shows the formal model of each WinWin conceptual entity. A WinWin conceptual entity is modeled as a first-class object that is defined by a set of tuples. Each tuple consists of the slot name denoting the relation name with a single or multiple cardinality and a typed value field that ranges over an object or enumerated value set. For example, in the win condition object W, the relation comment is a one-to-many function between win conditions and the set of all strings. Similarly the relation defined by the adopted-by slot in an option is a one-to-one function between the options and agreements. The state slot of each object is a one-to-many function from the object to an enumerated set of unary predicate constants. For example, a win condition can be in both active and at_issue state3. 3. The complete theory defining the state predicates [Bose95a] is beyond the scope of this paper. The WinWin Spiral Software Process Model November 20, t 995 12 TABLE 2.1\Jodd of the \Vin ;'Vin conceptual entities. a) Wincondition(W): Slot name Canlinalitv Value-Tvpe single string single string multiple term multiple string multiple win condition : multiple preuicate : multiple reason : single agreement single issue single wincondition State predicates: {active, covereu, at-issue, retracted, valid, reuuceu} b) Option(O) Slot name Cardinality Value-TYpe single string single string multiple term single agreement multiple constraint : single string : single string : multiple reason : multiple reason : multiple issue : multiple predicate S t.ate predicates {admissible, valid, adopted, at_issue, rejected, retracted} c) Issue(CRU): Slot name Caruinalitv Value-Tvpe single string si gle g taxonomy-eIs> multiple term : {W, 0, A} : ti l eason : multiple option state>: lt l predicate State predicates: {resolveu, unresolveu, nonresolvable, addresseu. retracteu} d) Agreement(POA) Slot name Cardinalitv : single : single multiple : multiple : multiple : multiple : single : multiple single State predicates: {open, acissue, replaced, retracted} Value-Tvpe string string term constraint {W,A} issue option predicate agreement valid, committed, Win Win-1 provides schema-based templates for each of the \Vin\Vin artifacts based on the model in Table 2. The templates can be instantiated and edited via the WinWin interface. An example of the win condition schema instance for multimission SEE for satellite ground stations is shown in Figure 3. The ConditionlRationalelConcerns slot specifies respectively the objective (SEE to support multiple concurrent missions: via extensions to general tools, simulation and test tools, the argument for the objective, and concerns for risks, conflicts and uncertainties, relative to the individual stakeholder's perspective. The Taxonomy Elements slot makes explicit the conjunction of domain-specific terms used in the definition of the objective. The Status and Contribute-to slot makes explicit the current state of the win condition and its relation to other WinWin schema The WinWin Spiral Software Process Model Novem~r 20. 1995 13 instances like issues and agrec;nents, respectively. Similar templates are defined for Issues, Options, and Agreements. Figure 4 shows examples of the issue (Contlict/Risk/Uncertainty) and option schema instance. The slots of the issue schema instance are very much simi1ar to the slots of the win condition schema except that the former has a Related Elements slot that specifies the win conditions and agreements which are in conflict and an Options slot that specifies the possible options for resolving the conflict. 111e option schema instance has a pros and cons slot that specifies the positive and negati ve ramification of the option. 4.3 Negotiation Support The second major problem encountered in using WinWin-O was handling conflicts arising from win conditions entered by different stakeholders. The experiment involved collaboration among multiple stakeholders. In WinWin-Q, the negotiation support was only in the form of capturing the end results of a negotiation activity. TI1is severely limited any use of the system in supporting the The Win Win Spiral Software Process Model Novc'!nI~r 20. 1995 14 negotiation for more complex conflicts. As a result, win condition clarification and resolution ~'tr activities tended to involve more free-ranging interpersonal discussions, often using a physical whiteboard to identify and discuss options. Also there were no trade-off analysis tools to support negotiating amongst stakeholders by exploring trade-offs among stakeholders' win conditions. In analyzing how Win\Vin could provide better support for resolving contlict via negotiation, we identified two major subproblems that the system must address: i) How to focus negotiation? and, ii) How to explore negotiated solutions? The first subproblem is addressed in WinWin-1 by making use of explicit representation for option summaries. As illustrated in Figure 5, the option summaries capture general conmet resolution principles within a domain, which get specialized to the conflict context by the system engineer. For example, the principle of "Defer functionality" to reduce cost to avoid a cost contlict, does not commit to a specific functionality. The negotiation process context does the specific binding via exploring refinements of such an option through the use of tools. This brings us to the Win Win-1 answer for the second subproblem of appropriate tools for exploring options and negotiated solutions. The current solution provided in WinWin-1 is limited to an interactive Constructive Cost Model (COCOMO) tool for cost/schedule! functionality/performance trade-off analysis. Planned WinWin enhancements in this area involve similar interactive tools for performance analysis and risk assessment. 4.4 Traceability and Navigation Support Two basic capabilities needed to SUpp0r1 a \VinWin type collaborative process are i) obtaining explanation by tracing through dependency links and ii) querying the state of the artifacts resulting from such a process. That is, for stakeholders to make an infonned decision at a specific choice point, they must be able to view their and others' win conditions, agreements and issues and their relations to other elements in the object base. Such a capability requires explicit representation of the dependencies between those elements that facilitate tracing of agreements to win conditions TIle WinWin Spiral Software Process MalleI So .•·ember 20, 1995 15 Name ,r~~velo~:e;~·;o:st·:·~checb..!.e conrlict ror aulti.i'3101 '},,;:.. :'.•.;:;:::..;.: ,,:... . Number ..~.•.... "' .... ~"-_..••......",, .., i CRU-I ,! ,:,,:::;,.. ;;'.Co,_ ••• ; ... Rationale ./.~:,::,~<;,.",,*,:,;:~,...,.-,.,220KDSI vill recover C03t. 3chedule Update Delete _. ._"",4 __ OM ••••• ••••• ~ •••••• FIGURE 4. An example of Win Win-l Issue (Conflict/Risk/Uncertainty) and option summaries. and support for query handling. WinWin-O lacked any capability to provide any such support; the need for such support was expressed in various ways in several of the experiment stakeholders' win conditions. WinWin-1 defines a set of relations bet\veen these Win\Vin. objects. Figure 5 shows a typical abstract structure of the dependency structure in terms of the above entities and the link types denoting the relations between them. As shown in the figure, an issue (I) is related to one or morestructure of the dependency structure in terms of the above entities and the link types denoting the relations between them. As shown in the figure, an issue (I) is related to one or more win conditions (\V x and \Vy) through the involves relation. An option (0) for resolving an issue (1) is related to the issue through the addresses relation. An agreement (AgD based on an option choice (Op) is related to Op through the adopts relation. The agreement (Agi)has a covers relation with a win condition and a replaces relation to any previous agreement it substitutes. The Win Win Spiral Software Process MOI.lel November 20, 1995 16 ~ adopts inVOlves~ addresses W = WinCondition Ag = Agreement I = Issue Op = Option FIGURE 5. Th~ Win\Vin d~dsion ohject') and r~lations hetw~~n them. Win Win-1 maintains the database of instances of the WinWin objects as they get created and revised and also maintains the hyperlinks defined by stakeholder. Such links provide the capability for the user to navigate through the dependency structure and construct explanations for issues. Also the dependencies can be traversed by query routines to retrieve objects and links via query. So, for example, the customer can find all the high priority user specific win conditions that are acti ve and relevant to product engineering tools by partially instantiating a win condition template with the values provided for only the relevant attributes of stakeholder, status and taxonomyelements. 4.5 Situated Process Definition WinWin-O was organized around prespecified processes which also defined the sequencing of the activities. The assumption made in Win\Vin-O was that the process would be generated first and then executed. In a collaborative context, most actions are primarily driven by the changes in states of artifacts resulting from other stakeholder's actions. This dynamic determination of the process actions based on the situation posed a limitation on the flexibility of the WinWin-O in allowing stakeholder's to enact activities relevant to the context of win conditions or point of agreements or conflicts. In a collaborative software process, activities are determined not only by specific process goals but also heavily determined by artifacts and their states resulting from actions of other individuals. The Win Win Spiral Software Process MoJeI November 20, 1995 17 The latter provides a product orie~ted and situation specific bias on the process elements. WinWin1 facnitates capturing such a bias in two ways: i) Implicit use of product oriented process environment: process activities in WinWin-1 are product or artifact centered; and ii) Tools to' support determination of relevant activities: this is done through use of trigger mechanisms which notify changes in the object base and make recommendations for relevant actions [Bose 95a]. 4.6 Change l'vlanagement and Coordination Support A major problem of WinWin-O was handling change an~ coordinating stakeholders activities driven by the change. The only change modeled in WinWin-O was process state changes such as start and completion of process activities. This was found to be inadequate for changes in the \Vin\Vin artifacts and their relationships (e.g. a win condition getting involved in an issue), The key problem to note here is that using a process to manage change and coordinate activity introduces goal orientation at the cost of flexibility of the stakeholder to act asynchronously and situation oriented. On the other hand the total freedom to create WinWin objects and their relations prevents effective coordination necessary to converge on a win-win solution. The above needs and issues were addressed in WinWin-1 by: i) defining a set of WinWin artifact states that captures desired goal states and states resulting from changes in the WinWin artifacts and their relations ii) defining the conditions under which the states hold, and iii) Operationalizing the conditions via trigger mechanisms that propagated state changes through the dependency relations and informed stakeholders of monitored state changes predicted plausible actions for desired states. Table 3. provides a listing of a subset of the states of the WinWin artifacts and specifies conditions under which they hold. The Win Win Spiral Software Proce:is Model November 20, 1995 18 TABLE 3. Theory defining th~ states of a suhset of the winwin ohject.~. i) Win Condition(!) active(W) ~ [ ['iR:reason, rationaIe(W, R) A valid(R)] V asserted("active~",'Wdb)] A -, retracted(W) acissue(W) ~ active(W) A [3 I:issue, involved-in(W, 1) ~ unresolved(I)] replaced(W) ~3 W':wincondition, replaced-by(W, W') A valid(W') A -, retracted(W) valid(W) ~ -, replaced(W) A acti ve(W) A [[ "I:issue[involved-in(W, I) ~ resolved(I)] A covered(W)] V [reduceu(W) ~ 'if\V' :winconuition, subwinc(W, W') A valid(W')]] covereu(W) ~ 3 A:agreement, covereu-by(W, A) A committeu(A) retracteu(W) ~ assened("retracteu(W)", Wdb) V [3 R:reason, rationale(W,R) A invalid(R)] V [3 I:issue, involved-in(W, I) ~ non-resolvable(I)] V [3 W':winconuition. replaces(W, W') ~ retracted(W')] V [3 W':wincondition. replaces(W, W') A 3A: agreement, covered-by(\V,A) ~ retracteu(A)] ii) Issue(!) unresolveu(I) ~ -,reu-acted(I) A [-,3 O:option[ auuresseu-by(I, 0) A admissible(O) A -, rejected(O)] V 3 O:option [ audn:ssed-by(I, 0) A valid(O) A -, adopteu(O) ] audressed(I) ~ 3 O:option, aduresseu-by(I. 0) A aumissible(O) A -, rejected(O) resolved(I) ~ 3 O:option, audresseu-by(I, 0) A valiu(O) A adopteu(O) nonresolvahle(I) <=> 'if O:option [auuressed-by(I. 0) A rejected(O)] retracted(I) ~ 'i X [involves(l, X) A retracted(X)] 4.7 Low Entry Barrier for Users The CACE-PNI support framework was graciously provided free of charge to USC by Perceptrorllcs. However, the use of WinWin-Q by any of the USC Center for Software Engineering's government and industry affiliates would have required them to pay a significant license fee for CACE-PM. This constituted a high entry barrier for nonUSC users of WinWin-O. One of the win conditions entered in the experiment by the Win\Vin customer (also representing the Affiliates as stakeholders) was to have a low entry barrier for Affiliate users in future versions ofWin\Vin. The resulting WinWin-1 implementation decision was to restrict WinWin-l infrastructure packages to commodity software packages. Reflecting other user and customer win conditions on WinWin portability, stability, and robustness, the commodity software packages chosen (XTIle WinWin Spiml Software Process MOtlel ~ovemba 20, 1995 19 Windows, Motif and Tool Talk) were also mature and based on open interfaces. As a result, there -has been considerable interest by Affiliates in importing WinWin-1 for experimental use.